that is great to hear EFM32 also use synopsys as their USB-IP. There is a pending issue #382 to generalize the ip driver much like ehci/ohci. If you could get it running on EFM32, then I guess it would help a lot in the generalization later on. Good news, that I also have an EFM M3 Giant Gecko (EFM32GG-STK3700) sitting on my storage for more than 5 years. Would be great to revive it :D .

Oh, right, I didn't look closely at the synopsys driver, fascinating.

So I didn't have time to test this until now, I'm only now trying.

I'm having a weird, unexpected issue, my device is hitting a HardFault on tusb_init I debugged the project and it seems to be failing at:

  // Init class drivers
  for (uint8_t i = 0; i < TOTAL_DRIVER_COUNT; i++)
  {
    usbd_class_driver_t const * driver = get_driver(i);
    TU_LOG2("%s init\r\n", driver->name);
    driver->init();
  }

because it tries to jump to init() on iteration i=1 but init() points to an invalid address at 0x20030000 the stack at that moment has:

driver: 0x0 <__Vectors>
driver.init: 0x20030000
driver.reset: 0x131 <Reset_Handler>
driver.open: 0x15d <WTIMER1_IRQHandler>
driver.control_xfer_cb: 0x106d <HardFault_Handler>
driver.xfer_cb: 0x1071 <MemManage_Handler>
driver.sof: 0x1075 <BusFault_Handler>
i: 1 '\001'

Its pointing to the vector table.

The call stack:

HardFault_Handler@0x0000106c (/home/perigoso/Development/tinyusb/hw/bsp/sltb009a/sltb009a.c:720)
<signal handler called>@0xffffffe9 (Unknown Source:0)
??@0x20030000 (Unknown Source:0)
tud_init@0x000014d4 (/home/perigoso/Development/tinyusb/src/device/usbd.c:396)
tusb_init@0x000014d4 (/home/perigoso/Development/tinyusb/src/tusb.c:50)
main@0x000014d4 (/home/perigoso/Development/tinyusb/examples/device/hid_generic_inout/src/main.c:79)

I will follow further.

Ok, I was unable to figure out why this looped more than once,

// Init class drivers
  for (uint8_t i = 0; i < TOTAL_DRIVER_COUNT; i++)
  {
    usbd_class_driver_t const * driver = get_driver(i);
    TU_LOG2("%s init\r\n", driver->name);
    driver->init();
  }

but i forced it to loop once (i < 1) and after chasing some gremlins with clocks the device enumerated successfully!

I have ordered a sltb009a efm32gg12 dev board from mouser which i will port and then i think we can merge this :) I can try to write support for the dev board you have @hathach , but I dont have one and its too expensive to justify buying so itll have to be blind

thank you, it is great to hear to get it working. If you could make an bsp for the board I have, that would be great, otherwise no problems at all, I found EFM32 dev board is rather expensive as well ( got it as freebie from energy micro a long time ago). I have also ordered sltb009a as well since that is probably most people will buy anyway. Looking forward to your PR.

Do you have any input into the // Init class drivers issue? I didn't figure it out I just overwrote it

Do you have any input into the // Init class drivers issue? I didn't figure it out I just overwrote it

hmm, can you log print the value of TOTAL_DRIVER_COUNT, it shouldn't have any issues, maybe there is some buffer overflow

It apparently resolves to 92

_app_driver_count is 91

hm, i think this is an initialization/startup issue, that variable is not cleared as it should, i tried to use silabs startup, gotta look at it

figured it out, by default silabs startup doesnt clear bss, i had to define __STARTUP_CLEAR_BSS, now _app_driver_count is 0, like it should.

I imagine this was causing issues in other places as well

figured it out, by default silabs startup doesnt clear bss, i had to define __STARTUP_CLEAR_BSS, now _app_driver_count is 0, like it should.

Yeah, I am glad we could figure it out, this probably causes lots of headache across the stack for sure.

Ok I have now tested a couple different examples, all without issues after enumeration, but there is one common issue, every time after initialization the devices times out

[ 5845.144641] usb 3-4.3: USB disconnect, device number 25
[ 5889.104950] usb 3-4.3: new full-speed USB device number 26 using xhci_hcd

[ 5904.562516] usb 3-4.3: device descriptor read/64, error -110

[ 5904.767196] usb 3-4.3: New USB device found, idVendor=cafe, idProduct=4004, bcdDevice= 1.00
[ 5904.767203] usb 3-4.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 5904.767206] usb 3-4.3: Product: TinyUSB Device
[ 5904.767210] usb 3-4.3: Manufacturer: TinyUSB
[ 5904.767213] usb 3-4.3: SerialNumber: 123456

this happens every time after reset, but after the first enumeration, the device re-enumerates fine, as in, unplugging and plugging back in, it's immediate (device is self powered for testing)

not quite sure how to debug this, I dont have a capable enough logic analyzer, I've looked at wireshark but no packets show up before the timeout, everything afterwards looks normal.

Superb !! That is really great to hear Don't worry if you couldn't fix it for now. I think it is already more than enough to wrap up this PR. I am still waiting for the sltb009a to delivery (probably in 2,3 weeks since I am so back ordering other boards as well). I could help to troubleshoot it afterwards with follow-up PR ( just make sure we have an issue for it so that we don't forget). I am actually quite familiar with these kinds of problems with enumeration.

did some minor cleanups, and removed the code for the board support, will create a seperate PR with it

You can merge

superb ! merged now, thank you very much.